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There is often a sort of a protocol associated to each class, stating when and how certain methods 
should be called. Given that this protocol is, if at all, described in the documentation accompanying 
the class, current mainstream object-oriented languages cannot provide for the verification of client 
code adherence against the sought class behaviour. We have defined a class-based concurrent object- 
oriented language that formalises such protocols in the form of usage types. Usage types are attached 
to class definitions, allowing for the specification of (1) the available methods, (2) the tests clients 
must perform on the result of methods, and (3) the object status — linear or shared — all of which 
depend on the object's state. Our work extends the recent approach on modular session types by 
eliminating channel operations, and defining the method call as the single communication primitive 
in both sequential and concurrent settings. In contrast to previous works, we define a single category 
for objects, instead of distinct categories for linear and for shared objects, and let linear objects 
evolve into shared ones. We introduce a standard sync qualifier to prevent thread interference in 
certain operations on shared objects. We formalise the language syntax, the operational semantics, 
and a type system that enforces by static typing that methods are called only when available, and by 
a single client if so specified in the usage type. We illustrate the language via a complete example. 



1 Motivation 

Today's mainstream object-oriented languages statically check code against object interfaces that de- 
scribe method signatures only. There are often semantic restrictions in the implementation of classes that 
impose particular sequences of legal method calls and aliasing restrictions, which clients must observe 
in order for objects to work properly. Usually, these usage protocols are only described in informal doc- 
umentation, and hence any disregard cannot be statically detected, revealing itself as a runtime exception 
(in languages equipped with built-in support to handle exceptional events) or, worse still, in memory 
corruption and unexpected behavior. 

In this paper, we present our work on the language MOOL, a mini object-oriented language in a 
Java-like style with support for concurrency, that allows programmers to specify usage protocols. The 
language includes a simple concurrency mechanism for thread spawning. Class protocols are formalised 
as usage types that specify (1) the available methods, (2) the tests clients must perform on the values 
returned by methods, and (3) the existence of aliasing restrictions, all of which depend on the object's 
state. 

Aliasing makes it difficult for a client to know if it is complying with the protocol since multiple 
references may exist to the same object, and may alter its state. In our approach, we define a single 
category for objects, as opposed to distinct categories for linear and for unrestricted (or shared) objects. 
We let the current status of an object to be governed by its type, allowing linear objects to evolve into 
shared ones (cf. iflTl 1221). The opposite is not possible, as we do not keep track of the number of 
references to a given object. We propose that the programmer explicitly introduces annotations in the 
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usage descriptor, in order to distinguish between lin and un object states. The lin qualifier describes 
the status of an object that can be referenced in exactly one thread object. The un qualifier stands for 
unrestricted, or shared, and governs the status of an object that can be referenced in multiple threads. The 
type system further maintains that unrestricted objects do not contain more restrictive linear attributes. 

In MOOL, we adopt an approach similar to the one of Gay et al. [8] defining a global usage speci- 
fication of the available methods. We spread the implementation of a usage type over separate methods 
and classes, following a modular programming principle. This means that we also have to handle non- 
uniform objects, that is, objects that dynamically change the set of available methods. Nierstrasz [ 17] was 
the first to study the behaviour of non-uniform, or active, objects in concurrent systems. We extend Gay's 
work in two ways. (1) The foregoing work treats communication channels shared by different threads as 
objects, by hiding channel primitive operations in an API from where clients can call methods. In MoOL, 
we eliminate channels and define a programming language that relies on a simpler communication model 
- message passing in the form of method calls, both in the sequential and in the concurrent setting. (2) 
The foregoing work deals with linear types only. In MoOL, we deal with linear types as well as shared 
ones, treating them in a unified category. 

Setting a single category for objects introduces an additional complication in the control of concur- 
rent access to shared objects. Since our main focus are linear objects, we adopt a standard and straight- 
forward solution similar to the synchronized methods used in Java in order to enforce serialised access 
to methods that manipulate shared data, and should not be executed by two threads simultaneously. 

Summing up the main contributions of our approach regarding session types for objects: 

• In contrast to other works |l4l l5l ISl , we elect method invocation as the only communication model 
in both concurrent and sequential programming; 

• We annotate classes with a usage descriptor to structure method invocation, and we enhance it 
with lin/un qualifiers for aliasing control, thus defining a single category for objects that may 
evolve from a linear status into an unrestricted one; 

• In contrast to other works on session types HI [131, we replace the shared channel primitive (on 
which sessions are started) by a conventional sync method modifier, enabling multiple threads to 
independently work on shared operations without interfering with each other. 

More examples, detailed explanations of the core language and of its implementation in a prototype 
compiler, as well as a more complete overview of the literature, are given in the MSc thesis of the first 
author 121. The remaining sections are organised as follows: Section [2] introduces the language via an 
example; Section |3] gives an overview of the language technicalities; and Section]?] contains additional 
discussion on related work, as well as an outline of future work. 

2 The Auction System 

Our auction system, adapted from ll20ll2TI . features three kinds of participants: the auctioneer, the sellers 
and the bidders. Sellers sell items for a minimum price. Bidders place bids in order to buy some item for 
the best possible price. The auctioneer controls these interactions. 

The system is best described by the UML sequence diagrams in Figures ]T] and [2j modelling the 
two main scenarios through a sequence of messages exchanged between objects. The first diagram de- 
scribes the scenario for a seller, while the second one describes the scenario for a bidder. We are mainly 
interested in visualising the interaction between the different players; we do not represent concurrent 
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communication, even though it should not be hard to imagine several seller and bidder threads concur- 
rently making requests to the same auctioneer object. To lighten the representation, we omit the usual 
dashed open-arrowed line at the end of an activation box indicating the return from a message and its 
result. Instead, we simply annotate sent messages with the returned value, if any. A conditional message 
is shown by preceding the message by a conditional clause in square brackets. The message is only sent 
if the clause evaluates to true. 

The first diagram (Figure[T]l depicts how a Seller initiates the interaction with the Auctioneer indicating 
the item to auction and its price. The Auctioneer, after creating an Auction object, where the bids for the 
item being sold are going to be placed, delegates the service to a new Selling object. Once the auction is 
set, the auctioneer can start receiving bids for that item. We signal with a note the moment when the two 
scenarios interweave. In the interaction initiated by a Bidder (Figure [2]), the Auctioneer receives a request 
for the item searched and, if the item is being auctioned, it delegates the service to the Bidding object. 
We can see that a Bidder holds its own Bidding object from which it can obtain the item initial price as 
defined by the Seller . Based on the returned value, the Bidder decides whether to make a bid by calling 
the appropriate method on the Bidding object. Back to the seller scenario, if the sale is successful, the 
Selling object allows a Seller to obtain the sale final price by invoking method getFinalPrice . 

Both scenarios depict a similar pattern, and it is not difficult to conclude from the diagrams that the 
usage protocols specified in the Selling and Bidding classes should be described by linear types. That is 
the only way we can guarantee that clients (sellers and bidders) fully obey the specification, by enforcing 
that their types are consumed to the end. A fresh Selling (and Bidding) object is created at the beginning of 
each selling (and bidding) interaction, and is implicitly destroyed at the end. We signal object destruction 
in the diagram to increase the expressiveness of the representation; the type system provides crucial 
information to object deallocation. 
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Figure 1 : The scenario for a seller 
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Figure 2: The scenario for a bidder 



Usage syntactic details Apart from the usage specification at the beginning of each class, our language 
presents a typical Java-like syntax. Before explaining the implementation in detail, we introduce some 
less obvious syntactic details. The usage formalises how clients should use an object of a given class. 
All methods that are not referred in the usage specification are not visible to clients. For the same reason. 
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class fields are also private, and cannot be used by other classes. 

If a program defines a conventional class named C with methods ml, m2 and m3, and no usage 
declaration, our compiler will insert usage *{ml + m2 + m3} as the class default usage type, where each 
method (ml, m2 and m3) is always available. Formally, this usage defines a recursive branch type of 
the form X.un{ml.X + m2.X + mS.X}. The un qualifiers are omitted in the examples. A choice between 
calling one of the three available methods is indicated by (+). Because of the particular form of the 
recursive type, calling any of these methods on an instance of C will not change the object state nor the 
set of available methods. 

A typical usage declaration for a linear object is a sequential composition of available methods. 
If C is linear, usage lin ml; lin m2; lin m3; end; is a possible usage declaration. Calling methods in the 
prescribed order on an instance of this class changes the object state and the set of available methods. 
State end is an abbreviation for un {}. When an object is in this state, it means that the set of available 
methods is empty (the usage protocol is finished). 

A variant type, denoted by (... + .. .), is indexed by the true and false values returned by the method 
to which the variant is bound. A client should test the result of the call: if true is returned, the new object 
state, and the available methods, are to be found on the left-hand side of the variant; if false is returned, 
it is the right-hand side to dictate the object state and available methods. 

Programming with usage types Consider now the usage specification in Figure [3] When an object 
of the Auctioneer class is created through the explicit constructor init , only one reference exists to it, but 
then the object evolves into an unrestricted type, allowing several sellers and bidders to hold references 
to the same instance. Notice that we have defined a recursive (shared) type. Each client object can do one 
of two things: (I) it can call method selling to obtain an object that provides an implementation of the 
selling activity on the auctioneer; or (2) it can call method bidding and obtain an object that implements 
the buying activity on the auctioneer. Then, it can repeat the interaction all over again: a seller can lower 
the price of an item with no bids, and start a new sale; a bidder can bid a higher price. The type never 
ends, and this illustrates why, in any program, we cannot keep track of the number of references to a 
shared type. The return types of these two methods are Selling [Sold] and Bidding[ Register] respectively, 
because the types of the returned objects have advanced during the execution of each method body. In the 
example, the state Sold is short for lin sold ; (getPrice; end -i- end); (lines 3 and 4 in Figure [6]l, where (;) 
binds stronger than (-I-), and is used for convenience to replace the full type above. In declarations, 
variable types are shortened (for space reasons), but their full types are implied. 

Notice, still in Figure [3j that when a new selling request is made, a new Auction object is created 
(line 10). This instance is then added to the AuctionMap object (whose class we omit), where the Auctioneer 
keeps all the auctions (line 12), and is passed to the constructors of both the Selling and Bidding objects. 
In the selling method, the reference to the Auction is created locally within the method body and assigned 
to the variable named a (line 10), while in the bidding method, it must be fetched from the AuctionMap 
object (line 20). It is through reading and writing to this shared Auction object that the protocol takes 
place. 

The usage declaration in the Auction class (Figure |5]l shows another example of a recursive type in a 
shared object. Notice also the sync method qualifier (line 10) that is used to control concurrent bids made 
by separate Bidder threads. This annotation also qualifies the put and get operations in the AuctionMap 
class (omitted). 

Figures [4] and |6] implement two linear types. The usage declaration of the Seller class (Figure [4]) is 
an abbreviation for the nested composition of branch types lin { init ; lin {run; un{}}}. An example of a 
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1 class Auctioneer { 

2 usage I i n i n i t ; 

3 *{selling + bidding}; 

4 AuctionMap map; 

5 unit init() { 

6 map = new AuctionMap () ; 
V } 

8 Se 1 1 i n g [ Sold ] se 1 1 i n g ( st r i n g 
int price) { 
Auction a = new Auction (); 

a . i n i t ( item , price); 
map . put ( item , a ) ; 
Selling s = new Selling () ; 
s . init (a); 
s ; // return s 



1 class Auction { 



item 



9 
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14 
15 
16 
17 
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19 
20 
21 
22 
23 } 



} 

Bidding [ Register ] bidding( 

string item) { 
Bidding b = new Bidding (); 
b . init (map .get(item)); 
b; // return b 



Figure 3: An auctioneer 



it; I i n run; end ; 
int price ; 
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23 } 



class Seller { 
usage lin ini 
string item 
Auctioneer a; 
unit i n i t ( A u ct i o n ee r a, 

string item, int price) { 
... // initialize fields 

} 

unit run() { 

Selling[Sold] s = 

a . s e 1 1 i n g ( item , price); 
// wait for the auction to end 



if (s. sold 0) 

print ("made " + 

s.getPrice() + " euros!"); 
else i f ( lo we r P r i ce ( ) ) 
run (); 

} 

boolean lowerPrice() { 

... // implementation omitted 

} 



2 

3 

4 

5 
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7 
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15 
16 

17 } 



usage lin init; Choose 
where Choose = *{bid + g e 1 1 n i t i a I P r i c e 
+ g e t F i n a I P r i ce + getBidder}; 
string item; int initPrice; 
int bidder; int finalPrice; 
unit init(string item, int initPrice) { 
... // initialize fields 

} 

sync unit bid(int pid , int bid) { 
if (finalPrice <= bid) { 
bidder = pid ; 
finalPrice = bid ; 



// the getters 



Figure 5: An auction 



1 class Selling { 
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14 } 



usage lin init 
where Sold = 



Sold 
lin sold; 
(getPrice; end + end) 
Auction [ Choose ] a; int finalPrice; 
unit i n i t ( Auction [ Choose ] a) { 
... // initialize fields 

} 

boolean sold () { 

finalPrice = a . get F i n a I P r i ce ( ) ; 
finalPrice >= a. getlnitialPrice (); 

} 

int getPrice() { finalPrice; } 



Figure 6: A selling protocol 



1 class Main { 

2 unit main () { 

3 Auctioneer a = new Auctioneer() 

4 a . i n it ; 

5 Seller seller = new Seller (); 

6 seller. init(a, " psp" , 100); 

7 spawn seller. run(); 

8 Bidder bidderl = new Bidder(); 

9 bidderl . i n it (a , 1 , 100); 

10 spawn bidderl . run ; 

11 Bidder bidder2 = . . . 

12 } 

13 } 



Figure 4: A seller 



Figure 7: The main class 
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(class declarations) 
(field declarations) 
(method declarations) 
(method qualifiers) 
(types) 
(values) 
(expressions) 



(class usage types) 
(type qualifiers) 



D 

F 
M 
s 
t 

V 

e 



q : 



= class C {m;F;M} 
= tf 

= St m{t x) {e} 
= e I sync 

= unit I boolean | C[u] 
= unit I true | false | o 
= V \ X \ o.f 

I e;e \ o.f = e 

I new C() I o.m{e) \ o.f.m[e) 

I if (e) e else e \ while {e) e 

I spawn e 

::= q {mi;ui]ia \ {u + u) \ 
I X I fxX.u 
= lin I un 



Figure 8: User syntax 



variant type is provided in the Selling class (line 4 in Figure [6]l. A variant type is always linear, so the 
redundant lin qualifier can be omitted. This type requires that the client evaluates the returned boolean 
value of the sold method in order to determine the next available method: if the value evaluates to true, 
then the caller can obtain the price via getPrice (because the item was sold), otherwise the interaction 
ends. 

The lowerPrice method in the Seller class (Figure [4]) is not referred in the usage specification (and is 
thus omitted from the object type). Our type system ensures that only methods in the usage type are 
visible to clients {cf. [8]). All methods not specified in the usage type can be accessed from their own 
classes, but never alter the type (otherwise client views of the object could become inconsistent). 

Finally, the Main class in Figure [7] creates an Auctioneer object that controls the auction, and spawns a 
separate thread for a Seller and two Bidder objects, using a Java-hke technique for thread creation. 



3 The Core Language 

Most of the technicalities that we now present are based on the core language from modular session types 
by Gay et al. |8|, and on the linear type system presented by Vasconcelos |22|. Inspired by these ap- 
proaches to sessions types, our main challenge was the attempt to formalise the convergence of channels 
and objects in a simple concurrent object-oriented language. 

Syntax In MOOL, we distinguish between the user syntax and the runtime syntax. The former is 
the programmer's language, and is defined in Figure [8} the latter is only required by the operational 
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(values) 
(expressions) 
(contexts) 



e 



V 



= [_] I £;e \o.f = £ 

o.m{£) I o.f.m{£) 

if {£) e else e \ while {£) e 



uninitc[u] 



insync o e 



(lock flags) 
(object records) 
(heaps) 
(states) 



R 



h 



S 



I 



I 1 



I h,o=R 
(h; ei|...|e„) 



Figure 9: Runtime syntax 



semantics, and appears in Figure [9] 



In order to simplify both the operational semantics and the type system, we introduce some restric- 
tions on the syntax of specific constructs: (1) an assignment expression is only defined on fields (not 
on parameters); (2) a method call is only defined on a field of an object reference (not on an arbitrary 
expression); (3) it follows from the above that calling a method on a parameter requires assigning it first 
to a field; and (4) methods accept exactly one parameter. 

We assume that class identifiers in a sequence of declarations D are all distinct, and that the set of 
method and field names declared in each class contains only distinct names as well. Object references o 
include the keyword this, which references the current instance. In the examples, field accesses omit the 
prefix this; the compiler can insert it when needed. Method modifiers, which include the sync keyword, 
are optional, which we indicate in the syntax by the empty string e. 

The MOOL syntax defines non-object and object types. Non-object types include the primitive unit 
and boolean types. The unit type has the single value unit, while the boolean type comprises two values: 
true and false. The type of an object is C[u\ in the style of modular session types [8], describing an object 
of a class named C at usage type u. From a client class perspective, it prescribes the structure of method 
invocation: in which order/how methods should be called. 

The MoOL expressions are standard in object-oriented languages. We have defined (in order of ap- 
pearance) values, parameters, fields, the sequential expression composition, assignment to fields, object 
creation, the self-call, the method call on fields, control flow expressions, and thread creation using the 
spawn primitive. The form of the spawn expression means that the inner expression e is evaluated in a 
newly created thread. 

In the core language, only the abstract syntax of usage types is defined, omitting the usage and where 
clauses, and the branch choice (-I-) and recursive (*) operators that have been introduced in the examples. 
However, it is not difficult to translate from the syntax of the examples into the core language syntax. For 
example, the recursive type usage lin init ; *{ selling -i- bidding}; in the Auctioneer class takes the following 
configuration in the core language: lin{init;/xX.un{selling.X,bidding.X}}. 

Branch types are denoted by {/M,;M,};g/, defining available methods m,- and their continuations m,-. 
Variant types are denoted by (m + m), and are indexed by the two boolean values, true first. In order to 
resolve the type, the caller must perform a test on the result of the preceding method. For simplicity. 
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{h; ei \ . . .\e\ . . . — > {h'; e\\. .. \e'\ . . . \e„) 
(R-CONTEXT) | . . . |^[,] | . . . |,^) ^ e,\ . . .\£[e']\ . . .\e„) 



(R-Spawn) {h; ei\... |<f [spawn e]\... — > {h; ei\... \£[un\t]\e\ . . . \e„) 
Figure 10: Reduction rules for states 



we use binary-only variants as in typestates |T8l, but more generous variants using enumerations can 
be found in the literature [8|. Recursive types are indicated in the syntax by hXm, and need to be 
contractive, which means that no subexpression of the form jJ-Xi.- • • /xX„.Xi is allowed [8|. These types 
are treated in an equi-recursive discipline, which means that we regard nX.u and its unrolling u{^^ "/x} 
as equal types. 

A usage branch type is annotated with a qualifier q for aliasing control. Recall that we define a single 
category for objects, as opposed to distinct categories for linear and for unrestricted objects, allowing 
linear objects to evolve into a status where they can be shared by multiple clients, but not the opposite 

{cf. mm). 

The type system, that we introduce later, imposes some further restrictions on usage types, namely 
that: (1) the initial class usage type must be a branch, because a variant type is bound to the result of 
a method call; (2) in a variant type configuration (u + u), each u corresponds to a lin-qualified variant 
(and that is why the qualifier is always omitted); (3) an object final status is always unrestricted, whether 
because it evolves into an end state (with an empty set of alternatives), or because, being recursive, it 
never ends, as illustrated in the examples; and (4) unrestricted objects may not contain linear attributes. 

The runtime syntax in Figure [9]introduces additional elements required by the operational semantics, 
but not available in the user syntax. Values include uninitc[u], which is used by our compiler to initialise 
fields of type C[u] when an object is created. Expressions are extended with the insync expression in the 
style of Flanagan and Abadi L7J, denoting that the subexpression e is currently being evaluated while the 
lock is held on object o. 

Evaluation contexts are denoted by £, and are expressions with one hole. Contexts specify the order 
in which expressions are evaluated, defining where reduction rules can be applied. A heap is viewed as a 
map (a partial function of finite domain) from object identifiers o into records R. The operation h,o = R 
adds an entry to the heap h, if o does not yet exist, and is considered to be associative and commutative, 
which means that a heap is an unordered set of bindings Object records are instances of usage-typed 
classes and are represented by the triple {t,l,f = v), where t is the object current type, / represents the 
object lock flag, and / 1— v is a mapping from field identifiers to their values. The lock can be either in a 
locked or unlocked state, denoted by the 1 and flag, respectively. The record (_, 1,_) means that some 
thread currently holds the lock associated with the current instance. Initially, an object is created with the 
flag set to 0. States consist of two components: a heap and a parallel composition of expressions sharing 
the heap. 



Operational Semantics Figure 10 defines the reduction rules for states, taking the form of a parallel 
composition of expressions: 



{h; ei 



(/!'; e[\...\e'^ 



20 



Channels as Objects 



Predicates lin(v) and un(v) with <7 ::= lin | un 

• if V = unit, true, false then un(v) 

• if V = o and /z(o). usage = (_ + _) then lin(v) 

• if V = o and /j(o). usage = q {...} then ^(v) 
Predicates lin (f) and un(f) witii ^ ::= lin | un 

• if f = unit, boolean then un(f) 

• if? = C[(_ + _)]thenlin(0 

• if t = C[q {...}] then q{t) 
Function init(f) 

• init(boolean) = false 

• init(unit) = unit 

• init(C[M]) = uninitc[u] 

Figure 1 1 : Auxihary functions for values and types 



R-CONTEXT is standard, defining which expression can be evaluated next in the program execution. 



It is the rule that invokes all the other reduction rules for expressions (see Figure 12 1. R-Spawn de- 
taches the expression to a new thread running in parallel. After spawn, the original thread proceeds to 
evaluate its next instruction. The value of the spawn expression is unit, as the result of evaluating e is 
not transferred back to the original thread. 



The rules for expressions in Figure 12 take a similar form, with the state containing only one expres- 
sion: 

{h; e) {h'; e') 



The rules use in their definitions the predicates defined in Figure 1 1 Predicate ^(v) determines the 
type status (linear or unrestricted) given a value v. If v is a value of a primitive type, then its status is 
always unrestricted. If v is an object, then its status depends on its current type, which can be fetch from 
the usage component of the record associated with o in heap h. A variant type is always linear, and the 
status of a branch type is defined by the programmer. Predicate q(t) follows a similar pattern, with the 
difference that it takes a type as its argument. Finally, function init(f) takes a type as its argument and 
returns the type default value. 

R-LinField and R-UnField extract the value of the field from an object in the heap and determine 
whether the value belongs to an unrestricted or a linear type. After access, the value of an unrestricted 
field is V as in Java, but the value of a linear field must be unit to ensure that only one reference to an 
object with a linear type exists at any given moment. 

R-Seq reduces the result to the second part of the sequence of expressions, discarding the first part 
only after it has become a value. R-ASSIGN updates the value of the field with value v. The value of 
the entire expression needs to be unit (as opposed to v), and this is again a linearity constraint. R-New 
generates a fresh object identifier and obtains the field names and types from the set of the class fields. 
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h(o).f = v lin(v) h(o).f = v un(v) 

(R-LinField) \ ' , ^ ^—^ — - (R-UnField) ^ ' ^ ' 



{h; o.f) — > {h{o.f I-)- unit}; v) {h; o.f) — > {h; v) 

(R-Seq) {h; v;e) — > {h; e) (R-ASSIGN) (/i; o.f = v) — > {h{o.f^v}; unit) 

o fresh C.fields = F/ 



(R-New) 



{h; newCO) — > (/z,o = (C,C.usage,0)/ = init(r); o) 
_m{_x) {e} G (/j(o). class). methods 



(R-SelfCall) 



(R-Call) 



(R-SCall) 



{h; o.m{v)) {h; 47this}{7x}) 

m e /j(o)./.usage _ m{_x) {e} G (/j(o)./.class). methods 
{h; o.f.m{v)) {h; e{"-f/,uis}V/x}) 

/i(o)./.lock = m £ h{o) .f .usage 
sync_m(_x) {e} G (/z(o). /.class). methods 
(h; o.f.m{v)) (M(o)./.lock^ 1}; insync o e{'^/Ahis}{7.}) 



(R-InSync) {h; insync o v) — > (/j{(o).lock H> 0}; v) 

(R-IfTrue) {h; if (true) e' else e") — > {h; e') (R-IfFalse) {h; if (false) e' else e") — > {h; e") 

(R-While) (/i; while {e) e') — ^ {h; if {e) {£'';while {e) e'} else unit) 
Figure 12: Reduction rules for expressions 

Notice that a new object record, indexed by the object identifier o, is added to the heap, that the object 
starts in an unlocked state 0, and that function init(?) takes a type as its argument and returns its default 
value. 

R-SelfC ALL is for method calls directly on an object reference, which typically result from calls on 
this. These calls do not depend on the usage type, unlike rule R-Call. In both rules, if the hypothesis 
holds, then the method body is prepared by replacing occurrences of this by the receiver heap address (so 
that occurrences of this within the method body refer to the receiver instance) and the actual parameter 
by the formal one. The resulting expression is the method body with the above substitutions that can be 
further reduced using the appropriate rules. 

R-SCall is for synchronized calls. The operational semantics proposed by Flanagan and Abadi Q 
inspired this and R-InSync. The new element here is the lock acquired on the receiver object, which 
is released in R-InSync, by updating the lock component with the flag 0. R-IfTrue, R-IfFalse and 
R- While are standard. 
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Subtyping The subtyping definition for the MOOL language is similar to the one described for the 
language in [8]. The subtype usage relation <:, defined by co-induction, includes the following rules: 

• If q{mi : <: u' then u' = q{mj : u'j} j^j with / C / and Vj G J,Uj <: u'j 

• If M <: {u' + u") then u' <: u or m" <: u 

The branch type is the source of subtyping by allowing that the possible usage choices can safely be 
used in the context where the superusage is expected. The proof that the usage relation is a pre-order (i.e. 
a relation that is reflexive and transitive) is not provided here, but can be adapted from 0. 

The subtyping usage rule relation is extended to the types of our language as the smallest reflexive 
relation which includes the following: C[u\ <: C[u'] if m <: u'. This means that implicitly the subtyping 
relation for the two other types in our language is defined as boolean <: boolean and unit <: unit. 

Type System The inference rules that define the type system use two typing environments, and P. 
We consider typing environments as maps (or partial functions of finite domain) similarly to heaps. The 
typing environment is a map from usage types u to typing environments F, and records the field typing 
environment associated with usage type u. It is used to keep track of visited usage types, thus preventing 
cycles in the presence of recursive types. 

The typing assumptions for the environment F have the form: 

F ::= £ I (F + F) 

where £ is a map from fields o.f and parameters x to types t. The environment (F + F) represents a pair 
of maps: the map on the left is used for the true variant, while the map on the right is for the false one. 

Below are the typing judgements where these environments are used. The typing judgement for 
usage types is presented on the left, and the one on the right is used for expressions: 

@;r>cu<r' r>e:t<r' 

The typing judgement for usage types reads: "A usage type u is valid for a class named C starting 
from field and parameter types in F, the initial environment, and ending with field and parameter types 
in F', the final environment". The initial and final environments may be different, because object field 
types in F may have changed after each method described in u has been type-checked. 

The typing judgement for expressions follows a similar pattern. F is the initial typing environment 
before type-checking the expression e, and F' is the final one, after associating e with the type t. Again, 
the initial and final environments may be different, because of side-effects the expression being checked 
may cause on the environment F, turning it into the environment F'. In particular, identifiers may become 
unavailable in the case of references to linear objects, and object types may change as a result of the 
evaluation of some language constructs, namely method calls and control flow expressions. Using a 
similar notation to the one used to update the heap, if F(o./) is defined, i.e., if o.f G dom{r), then 
F{o./ 1— t} denotes the environment obtained by updating to t the type of o.f . 

The typing rules defined for MoOL have a clear algorithmic configuration, and type-checking is 
modular and performed following a top-down strategy: a program checking is conducted by checking 
each class separately, which in turn conducts the checking of each method within the class in the order 
in which it appears in the specified usage type. In what follows, rules are presented in the order in which 
they are evaluated by the type-checker (and in the order in which they should be read). 

Figure [13] defines rules for typing programs. When checking that a program is well-formed, T- 
Program simply checks that each class defined in it is well-formed. T-Class constructs the field 
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„ . \-Di ... \-D„ 0;this./ :7i>c M<ir un(E) 

(T-Program) ^- — - (T-Class) ' ■> ^ ^ ^ 



^Di...Dn \- class C {u;tf;_} 

Figure 13: Typing rules for programs 



(T-B RANCH) 



V/ G / Si ti mj{t- Xi) {ei} £ C.methods q{ll) L,Xi : t'->ei : ti<r 
Xi : G r ^ u n {t'/) T =(_ + _) ^ = boolea n 0; r\;c; > c «; < T' 



(T- Variant) 



&;L>c q {mi;ui}<r' 

0;(r+r")>c {ut + uf)<r 



(T-UsageVar) (0,X : F);Fc>c^<ir (T-Rec) -^^^ 

0;F>c IJ-X.u<V 

Figure 14: Typing rules for classes 



arguments in the initial typing environment. Notice that when starting to type-check a class, the environ- 
ment is empty as no usage types have yet been visited. T-Class is responsible for calling the rules 
for type-checking usage type constructs (see Figure 14 1. After type-checking u, the object fields in £ are 
a subset of the original ones, that have been consumed, inside the object, to the end. Those which are 
missing have been passed as parameters, or returned from methods, and thus removed from the environ- 
ment. This means that the object fields in a class final environment have always unrestricted types, either 
an unrestricted recursive type or un end. Function un(r) recursively calls predicate q{t), passing each 
field type in £ as argument, in order to guarantee that no linear fields exist in the class final environment. 
We also define q{L) if and only if o.f : ? G £ implies q{t), so that the type system can check that no linear 
fields are allowed in shared objects. 

The rules in Figure 14 describe how the four usage constructs (cf. Figure [8]l are typed in MOOL. T- 
Branch conducts the type-checking of the methods defined in the class usage type in the order in which 
they appear in the specified sequence. The appropriate rules for expressions (see Figures 15 and 16 1 are 
called by T-Branch so that each method body e, can be type-checked. The initial environment is a 
single map of fields and parameters, denoted by £, while the final one may be a pair of maps if the 
method m,- returns a value of type boolean. Thus F is used instead. The relation q Cq' i& reflexive and 
transitive, and in particular lin C un. When exiting the method body, the parameter type in F may have 
changed from the initial type t- to the final one t-'. Additionally, the rule requires that t'/ is unrestricted, 
so the function un{t'/) checks that the parameter has been consumed to the end. Finally, the parameter 
entry must be removed from F before the rule advances to type-checking the method continuations m,, 
where again the field typing may change, modifying the initial environment F to the final one F'. 

In checking variant types, T- VARIANT requires a consistency between the variants final environment 
F, after passing F', the left environment, to type the true variant, and F", the right environment, to type 
the false variant. T-UsageVar simply reads the type variable X from map 0. Because X represents an 
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™ T -,7 N lin(0 un(0 
(T-LinVar) ^ ^-2 ^ (T-UnVar) ^ ^ 



,„ T 1- \ \\n(t) un(t) 
(T-LinField) — '-1-^ ^ (T-UnField) ^ ' 



L,o.f ■.t>o.f -.kL L,o.f ■.t>o.f ■.t<L,o.f -.t 



r>e;e':?'^r £i>o./ = e : unit<]£' 

(T-New) r> new C() : C[C.usage] <r (T-Spawn) 

ri> spawn e : unit<ir 

Figure 15: Typing rules for simple expressions 



infinite branch in the usage type tree that no program can ever consume to the end, the rule cannot define 
the final environment as being the same as the initial one, which means that the final environment can be 
whichever we want. T-Rec, not only reads the type from 0, but also checks the type against the class, 
using T-UsageVar to type usage variables X, and the other two rules, T-Branch and T- Variant, 
to type branch and variant constructs. The final environment V may be different, because field types 
may have changed, after type-checking expressions in method bodies (recall that T-B RANCH calls the 
appropriate rules for expressions). 

We now present the rules for expressions. In order to make them more readable, we use the single 
environment £ everywhere a map is needed to index a field or a parameter; otherwise the more general 
r is used. Figures 15 and 16 define the rules for the remaining expressions of the top level language. 

T-LinVar and T-UnVar evaluate the types of method parameters, distinguishing linear from un- 
restricted ones. Recall that, as we cannot call methods on parameters, they must be first assigned to 
fields. In the case of parameters with linear types, the type system requires that they are removed from 
the environment, so that they can no longer be used after assignment. Predicates lin(f) and un{t) are used 
to determine the status of a given type. In practice, primitive types (unit and boolean) are always unre- 
stricted; for object types the current status varies with the type. T-LinField, T-UnField are similar to 
the rules defined above for parameters, removing fields with linear types from the environment. 

Typing the sequential composition of expressions is simple: T-Seq considers the typing of the second 
subexpression taking into account the effects of the first one on the environment, which may be different 
when e represents a method call or a control flow expression. T-ASSIGN formalises assignments to 
fields. The type of the reference and the expression must be consistent and, because of linearity, it must 
be unrestricted. The type of the entire assignment expression is unit (as opposed to t) to enforce that 
a linear reference goes out of scope after appearing on the right-hand side of the assignment. T-New 
simply states that a new object has the initial usage type declared by its class. T-Spawn requires not 
only that the thread body is typable, but also that it is not of a linear type; otherwise one could create a 
linear reference and not use it to the end (suppose we wrote spawn new C()). The type of the entire spawn 
expression is unit, because the evaluation is performed only for its effect (creating a new thread); no 
result is ever returned. 
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(T-Call) 



r>e:t<'L i:{o.f) =C[_{mi;ui}iei] 
i^I f my (f a;) {_} G C. methods 



r>o.f.mj{e) ■.t<'L{o.f^C[uj]} 



(T-IfV) 



r>o.f.m{e) : booleanoZ ^{o-f) = C[{ut + Uf)] 

I.{o.f ^C[ut]]t>e' -.kV I.{o.f^C[uf]]t>e":t<r 
roif {o.f.m{e))e' else e" \t<r 



(T-WhileV) 



r>o.f.m{e) : boolearKiZ 
£(o./) = C[(Mf + I,{o.f^C[u,]}>e':t<r 
Fowhile {o.f.m{e)) e' : unitoZjo./ i-> C[m/]} 



™ Tog: boolean <]r rt>e':t<T" T'\>e":t<T" 
T\>\^ {e)e' e\see" -.kT" 

Tog : boolearKiT V^e'-.t^T 
Fowhile (g) e' : unitoF' 



(T-While) 



(T-INJL) ^^^7^^' „ (T-INJR) ^>e:t<Y" 



rog:f<i(r + r") Yt>e:t<{r + T") 



(T-SUB) ^^--^M^r C[u]<:C[u'] (T-SUBENV) T^-Ml £<:£' 



r>g:c[M']<r' r>g:M£' 

Figure 16: Typing rules for calls and control flow expressions 



T-Call requires that the receiver has an appropriate usage type. The call results in the receiver 
changing its type to C[uj\, with the final environment £ being updated accordingly, while at the same 
time the type advances from {m;;M,} to Uj. 

As opposed to the rules presented thus far, the remaining ones in Figure [16] are not syntax-directed, 
which means that to implement them additional information is needed as they are evaluated. To simplify 
the rules, for an object to have a variant type, the method call on which the variant type depends must 
be performed on the condition of a control flow expression (and not on an arbitrary assignment). Recall 
that a variant type is tied to the result of a method and, depending on the value returned, an object type 
may be modified differently. The type system requires that the value is tested on the condition of the 
expression, so as to have the type immediately deduced. We believe that this restriction does not impair 
current object-oriented programming practices, as it reflects how a variant type is typically given to an 
object. 

T-IfV and T-WhileV are particular cases of the more general rules for control flow expressions that 
we describe below. The order in which we present them here corresponds to the actual order in which 
the type-checker evaluates them. Both rules depend on T-Call to deduce the return type of the method 
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tested on the condition. In the case of T-IfV, both branches use Z, the environment that results from 
the call, as their initial environment. The method returned value defines how o.f type is updated, thus 
determining which branch (the then or the else) shall be executed. However, because only one of the 
branches can be executed, the rule enforces that the two branches should be consistent, sharing the same 
final environment V. T-WhileV follows a similar pattern: a while expression can be reduced to an if 
that is repeated while a particular condition returns true. The type of the entire loop expression is unit, 
because its result can never be used. T-lF, T-While are standard rules for control flow expressions, and 
should be used only after the above rules have been tried. 

T-InjL and T-lNjR build a variant environment as follows: an environment F becomes (F + F') by 
injecting F on the left using rule T-InjL, and becomes (F' + F) by injecting on the right using rule T- 
INJR. Typically, these rules build the final environment of a boolean method to which a variant is tied. 

T-SUB and T-SubEnv are similar to the subsumption rules described for the language in modular 
session types [8j. T-SUB is a standard subsumption rule that simply says that whenever we can prove 
that type t' is a subtype of f, we can treat t' as if it were type t. T-SubEnv allows subsumption in the 
final environment, and is used for the branches of control flow expressions. 

4 Concluding Remarks 

Session types, introduced in lfT2l [T3l [T9l . have been proposed to enhance the verification of programs 
at compile-trme by specifying the sequences and types of messages in communication protocols. Tradi- 
tionally associated with communication channels, session types provide a means to enforce that channel 
implementations obey the requirements stated by their types. Originally developed for dyadic sessions, 
the concept was then extended to multi -party sessions [11]. Programming languages that implement 
session types come in all flavours: pi calculus, an idealised concurrent programming language in the 
context of which the original concepts were developed, functional languages |T61 |2T1|23 I. CORE A EOl. 
object-oriented languages ||4j|5l[8l[T5l. Channels as conceived in session type theory are special entities 
that carry messages of different types, bi-directionally, in a specific sequence between two end points. 
These channels are usually implemented in a socket-hke style, and, to our knowledge, none of the pre- 
vious attempts to integrate session types into object-oriented programming ever abstracted this notion 
of communication channels. The work on Moose [4,. ^J, a multi-threaded object-oriented calculus with 
session types, was the first attempt to marriage the (concurrent) object-oriented paradigm and session 
types. Unlike our work, this and subsequent work have kept distinct mechanisms for local and remote 
communication, in the form of method call and channel operations, respectively. 

In the literature, several lines of research can be found that reveal similarities with session type 
theory. One of these lines introduces the concept of typestate lITSll in which the state of the object in 
some particular context determines the set of available operations in that context, based on pre- and post- 
conditions. Objects, by nature, can be in different states throughout their life cycle. The concept involves 
static analysis of programs at compile-time so that all the possible states of an object and associated legal 
operations can be tracked at each point in the program text. Typestate checking has been incorporated 
in several programming languages III S HI, and some ideas relate very closely to session type recent 
approach on modularity. 

This paper formalises a mini class-based language that uses primitives consistent with most object- 
oriented languages, and incorporates support for the specification and static checking of usage protocols. 
The existing work on modular session types [SI has been the inspiration for our specification language 
and type system, where we replace operations on communication channels by remote method invoca- 
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tions. Another distinguishing feature comes from allowing objects to change from a linear status to a 
shared one. We also use a standard synchronization mechanism to control concurrency, instead of the 
well-known shared channel on which linear channels are created. We have designed a simple operational 
semantics and a static type system which checks client code conformance to method call sequences and 
behaviourally constrained aliasing, as expressed by programmers in class usage types. 

One of the main limitations that can be pointed out to the technical discussion in this paper is that it 
does not cover a full formal treatment of the MOOL language, nor does it present proofs. However, we 
are confident that, with minor adjustments, we can adopt the techniques used in the work on modular 
session types IHl and apply them to our language. 

A feature which our system does not consider is the treatment of exceptions. We do not predict any 
sort of mechanism for letting a method throw a checked exception, so that a client can execute some 
predefined error-handling code when it happens. However, Java-like error-management techniques, or 
alternatively, some exceptional default state encoded in the usage type (see |[T4l ) could be easily added 
to our language. 

Finally, although we tried to introduce some flexibility in our approach to linearity by letting linear 
objects evolve into shared ones, we still have not quite found a middle ground: our language entirely 
bans the aliasing of linear types, while completely allowing the aliasing of unrestricted types. Allowing 
limited forms of aliasing without loosing track of an object state is a topic that has occupied many 
researchers, and which we also plan to pursue in future work. 

Acknowledgements This work was funded by project "Assertion-Types for Object-Oriented Program- 
ming", FCT (PTDC/EIA-CCO/105359/2008). 
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